-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defensive guards against invalid code points in preferences. #6094
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally a good move. Thanks for picking up!
On the protecting on import side -
- there are
.properties
files outside ofconfig/Preferences
. Are we 100% sure there is no valid reason for\u0000
in them? Or need to filter by preferences root? - does the import protection also need to be considered in - https://github.com/apache/netbeans/blob/master/platform/options.api/src/org/netbeans/modules/options/export/OptionsExportModel.java#L293 ? (yes, I love we have two code paths with somewhat different implementations of similar things!)
I scanned my config folder which had NB configs reaching back to NB 5. And none of them had this code point in properties files. #6076 (comment)
oh boy. No I have not. Going to take a look.
|
@neilcsmith-net good that you pointed me to I never used the zip export feature before. Lets test this a bit before merging. edit: tested config export/import and also config migration, everything worked fine I believe. Corrupted properties were also detected and successfully ignored. forgot to squash, will force push |
Made sure that OptionsExportModel is closing streams and zip files.
76fdd1b
to
a208c99
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about the \0 in properties, but the changes look sane and code is cleaner now.
thanks for the reviews and sorry for the delay. I am also not sure about the null code point as property value, but https://bugs.openjdk.org/browse/JDK-8068373 for example describes it being illegal in XML files. Given that a) there was no such value in any property in my config backups and b) properties could end up in xml at some point which makes it probably safer to filter them out during config migration. -> merging |
The code point '\u0000' breaks the Preferences storage as demonstrated in https://bugs.openjdk.org/browse/JDK-8068373, as preventive measure it can't be used in keys since https://bugs.openjdk.org/browse/JDK-8084823.
There are many reports of windows users running into seemingly unrelated issues, but closer investigation showed that they all had at some point "invalid code point" exceptions in the log.
this usually happens in a code pattern like this:
It is not clear what causes the corruption (and why it seems to only occur on windows), this PR adds some defensive code to cover some common cases, logs it and makes sure no corrupted properties files are imported from old configs on first launch.
the jackpot rule:
had 70 hits - this PR covers only common cases + adds the import filter.
closes #6076
closes #5147
closes #5633
closes #5634
https://bz.apache.org/netbeans/show_bug.cgi?id=271652
https://issues.apache.org/jira/browse/NETBEANS-3284